1. Statement of the Technical Field
The present invention relates to the field of computerized business-to-business interactions and more particularly to integrating cross enterprise business processes.
2. Description of the Related Art
The achievement of universal interoperability between applications by using Web standards remains the principal goal of Web Services. Web Services use a loosely coupled integration model to allow flexible integration of heterogeneous systems in a variety of domains including business-to-consumer, business-to-business and enterprise application integration. The following basic specifications originally defined the Web Services space: the Simple Object Access Protocol (SOAP), the Web Services Description Language (WSDL), and Universal Description, Discovery, and Integration (UDDI). SOAP defines an XML messaging protocol for basic service interoperability. WSDL introduces a common grammar for describing services. UDDI provides the infrastructure required to publish and discover services in a systematic way. Together, these specifications allow applications to find each other and interact following a loosely coupled, platform-independent model.
Presently, the interaction model that is directly supported by WSDL essentially can be viewed as a stateless model of synchronous or uncorrelated asynchronous interactions. Models for business interactions typically assume sequences of peer-to-peer message exchanges, both synchronous and asynchronous, within stateful, long-running interactions involving two or more parties. Nevertheless, systems integration requires more than the mere ability to conduct simple interactions by using standard protocols. The full potential of Web Services as an integration platform will be achieved only when applications and business processes are able to integrate their complex interactions by using a standard process integration model.
The Business Process Execution Language for Web Services (BPEL4WS) fulfills some aspects of a standard process integration model. The BPEL4WS specification defines a technology for integrating cross-enterprise business processes. By coordinating stateful interactions of loosely coupled services across enterprise boundaries, the BPEL4WS technology provides a means of modeling the interactions between an enterprise and its business partners, suppliers and customers and thus the value chain of the enterprise. More particularly, BPEL4WS defines a notation for specifying business process behavior based on Web Services.
In accordance with the BPEL4WS notation, business processes export and import functionality by using Web Service interfaces exclusively. Business processes can be described in two ways. First, executable business processes model the actual behavior of a participant in a business interaction. Abstract business protocols, by comparison, use process descriptions that specify the mutually visible message exchange behavior of each of the parties involved in the protocol without revealing their internal behavior. In any case, the BPEL4WS specification can be used to model the behavior of both executable and abstract processes.
BPEL4WS provides a language for the formal specification of business processes and business interaction protocols. By doing so, BPEL4WS extends the Web Services interaction model and enables the model to support business transactions. The basic concepts of BPEL4WS can be applied in one of two ways. A BPEL4WS process can define a business protocol role, using the notion of an abstract process. The relationship between two or more business protocol roles can be modeled as a partner link. Similarly, it is also possible to use BPEL4WS to define an executable business process. In an executable business process, the logic and state of the process determine the nature and sequence of the Web Service interactions conducted at each business partner, and thus the interaction protocols.
Importantly, where private implementation aspects of a business process use platform-dependent functionality, which is likely in many if not most realistic cases, the continuity of the basic conceptual model between abstract and executable processes in BPEL4WS makes it possible to export and import the public aspects embodied in business protocols as process or role templates while maintaining the intent and structure of the protocols. This is arguably the most attractive prospect for the use of BPEL4WS from the viewpoint of unlocking the potential of Web Services. Specifically, BPEL4WS allows the development of tools and other technologies that greatly increase the level of automation and thereby lower the cost in establishing cross-enterprise automated business processes.
Notwithstanding, BPEL4WS can be limited to the static deployment of selected business processes. In fact, whereas BPEL4WS provides for a statically specified abstract business protocol for a deployed process, BPEL4WS does not permit the dynamic specification of an abstract business protocol for a deployed process. More concisely, the business process execution environment does not define a process for adapting business protocols or executable business processes as a function of business insights modeled as business policies. The modern, on-demand computing vision, however, demands that the enterprise support a level of business transformation which is informed by timely and relevant business insights. Consequently, comprehensive business transformations require not only the modification of executable business processes, but also the adaptation of partner, supplier and customer interactions modeled by BPEL4WS as business protocols, or abstract processes.
In order to achieve true on-demand computing, there remains an implicit requirement that an enterprise support a level of business transformation which is informed by timely and relevant business insights gained during the execution of a business process. Comprehensive business transformations require not only modification of executable business processes, but also comprehensive business transformations must allow for the adaptation of partner, supplier, and customer interactions modeled as BPEL protocols, or abstract business processes. To that end, potential interaction modalities, such as personal computing clients, paging devices, handheld computing devices and cellular telephones, must be supported so that users can observe and interact with a business process in real-time regardless of the modality. In this way, participants to the business process can react with the greatest amount of efficiency to ever changing conditions in the business process. To date, there is no such method, system or apparatus which can allow for effective communication between business process participants and the underlying technology handling the business process—regardless of the modality of communication.